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ABSTRACT 

This  paper  presents  a  brief  description  of  the  Meteorological  and 
Oceanographic  (METOC)  system  and  a  discussion  of  various  aspects  of  the  METOC 
database  that  emphasizes  the  importance  of  combining  new  and  existing  technology. 
The  METOC  database  components  were  designed  according  to  a  database-centric 
architecture  to  assists  the  users  in  obtaining  up-to-date  information  from  the 
DII/COE  compliant  METOC  system.  The  Meteorological  and  Oceanographic 
(METOC)  database  is  a  dynamic,  distributed  database  that  conforms  to  the  DII/COE 
requirement  of  providing  general  availability  to  all  users  of  the  system.  Several  key 
aspects  of  METOC  database  technology  are  of  interest  to  various  users  who  have 
special  requirements.  Because  each  key  aspect  must  be  implemented  in  concert  with 
users  requirements,  some  adaptations  may  be  necessary.  The  most  important 
feature  of  a  database  server  from  the  user  perspective  is  its  capability  to  deliver  to 
the  user  the  required  information  in  a  timely  and  user-friendly  manner.  This  paper 
discusses  various  aspects  of  the  impact  of  technology  evolution  on  METOC  database 
and  its  impact  on  the  system  design  and  development  cycle. 


I.  INTRODUCTION 

The  Meteorological  and  Oceanographic  (METOC)  database  is  dynamic, 
distributed  database  that  conforms  to  the  Defense  Information  Infrastructure 
Common  Operating  Environment  (DII/COE)  specification  of  providing  general 
availability  to  all  users  of  the  system.  It  is  dynamic  because  it  is  filled  with 
perishable,  environmental  data  that  are  ingested,  updated,  and  deleted  on  a  regular 
and  real-time  basis.  The  METOC  database  is  distributed  not  only  with  respect  to  the 
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physical  locations  of  its  distributed  data  repositories,  but  also  with  respect  to  the 
applications  that  access  the  METOC  data.  It  consists  of  six  shared-database  segments 
that  comply  with  the  requirements  DII/COE  level  five  [8]. 

As  is  the  case  with  any  database,  each  of  several  key  aspects  of  METOC 
database  technology  is  of  interest  to  various  specialists  in  the  technical  community. 
For  example,  data  administrators  want  to  be  sure  that  the  design  of  the  database 
structure  meets  the  needs  of  the  organization  as  a  whole.  Database  developers  and 
engineers  implement  the  mechanics  of  designing,  building,  and  integrating 
databases  and  meta-databases  to  achieve  specific  goals  within  the  larger  context  of 
the  software  and  system(s)  that  the  data  support.  (See,  for  example,  [4].)  Database 
administrators  are  concerned  with  updating  the  database,  providing  users  with 
accounts,  maintaining  user  profiles,  and  with  the  overall  reliability  and 
maintainability  of  the  database  system. 

Finally,  one  must  consider  the  METOC  users'  perspective.  The  most 
important  feature  of  a  database  to  the  user  is  its  capability  to  provide  that  user  (or 
the  user's  software)  with  access  to  timely,  accurate,  up-to-date,  consistent  and  user- 
friendly  data.  This  paper  presents  a  discussion  of  various  aspects  of  the  METOC 
database  that  emphasizes  the  importance  of  technology  and  its  effect  on  the  user. 

II.  DESCRIPTION  OF  EXISTING  METOC  DATA  SERVER 
AND  DATA-ACCESS  METHODS 


Data-Centric  View 

To  eliminate  the  "stovepipe"  and  segregated  databases,  the  METOC  database 
takes  a  unified  database  topology  where  quality-controlled  data  can  be  disseminated 
to  the  applications  and  users  in  a  coherent  manner.  The  METOC  database  system  is 
a  data-centric  server  as  opposed  to  an  application-based  or  process-oriented  system. 
This  data-centric  architecture  is  similar  to  some  existing  environmental  systems  [10] 
as  well  as  C3I  [1]  systems  that  use  the  METOC  data.  From  the  C3I  systems  experience, 
this  data-centric  architecture  has  been  shown  to  be  of  great  utility  in  assisting  users 
with  their  data-access  tasks. 

Currently,  the  preferred  method  of  data  access  in  the  METOC  system  is  via 
application-program  interfaces  (APIs)  [8,  9].  These  APIs  provide  the  users  and  their 
applications  with  storage,  retrieval,  maintenance  and  distribution  of  METOC  data 
and  products  [8].  APIs  fall  into  three  categories:  American  National  Standards 
Institute  (ANSI)  Structured-Query  Language  (SQL)  APIs;  Tactical  Environmental 
Data  System  (TEDS)  APIs  [8];  and  Operating-  and  File-system  service  APIs  [8].  ANSI 
SQL-92  is  incorporated  into  the  API  code  to  make  these  APIs  independent  of  any 
specific  database  management  system  (DBMS)  vendor  enhancements  to  SQL.  Access 
via  direct,  ad  hoc  SQL  query  is  a  secondary  method  of  data  access  that  is 
recommended  only  for  the  database  system  administrators  or  when  APIs  are 
inappropriate. 


METOC  Data-Server  Design 


A  data-perspective  modeling  of  the  METOC  data  reveals  that  five  basic 
METOC  data  types  can  be  abstracted.  Since  the  original  analysis  [9]  of  the  METOC 
data,  two  additional  data  types  have  been  created  and  augmented  for  the  database. 

In  addition  to  the  observations,  numerical-prediction  model  output,  and  image 
types,  the  TEXT  data  type,  and  CLIMATOLOGY  data  type  have  been  added.  The 
additional  data  types  are  demanded  by  the  users  to  handle  those  data  related  to  the 
dynamic  data  of  the  METOC  environment.  Most  of  the  textual  data  are  in  the  area 
of  plain-text  warning  messages.  Although  they  do  not  record  continuous  variables 
of  the  nature  environment  (e.g.  temperature  of  the  atmosphere  or  ocean),  they  do 
record  a  particular  event  or  phenomenon  of  the  nature  environment  such  as  a 
tornado  or  a  tsunami.  The  climatology  database  contains  the  "average"  conditions 
of  the  natural  environment.  It  often  serves  as  a  background  and  describes  the  range 
of  expectation.  With  the  additions  of  these  two  data  types,  any  plain  text  or  fixed 
METOC  data  sets  can  be  adapted  to  these  two  types. 

The  most  challenging  aspect  of  the  design  of  a  data-centric  METOC  database  is 
to  provide  a  foundation  for  equal  efficiency  of  handling  of  all  five  data  types  (or  all 
six  DII/COE  database  segments).  Each  segmented  data  type  has  its  own 
particularities  in  terms  of  characteristics  of  the  data  volume  and  traffic. 

Observations  are  short  (hundreds  of  bytes)  with  large  volume  (about  two  million 
records  a  day).  Numerical  model  outputs  have  finite  data  sets,  but  they  arrive  at 
database  in  bursts  (twice  a  day,  about  200-500  Mbytes  each  time).  The  image  data 
reach  the  database  regularly  at  50  Mbytes  every  hour.  Text  observations  are  very 
infrequent  and  short  (hundreds  of  bytes).  Fixed  data  sets,  in  general,  are  the  easiest 
to  handle,  since  the  usage  of  these  data  sets  is  defined. 

When  an  application  or  a  user  extracts  data  from  the  database  server,  a 
performance  degradation  may  be  experienced  if  the  same  schema  for  the 
observations  is  used  to  serve  the  numerical  model  output.  METOC  data  server 
design  in  the  current  implementation  can  take  advantages  of  the  "segmented" 
architecture  provided  by  the  DII/COE.  Each  data  type  is  a  segment  and  can  be 
implemented  separately  on  separate  servers.  The  advantage  is  two  fold: 

•  not  all  data  types  have  to  be  implemented  on  one  server,  and 

•  network  segmentation  can  be  done  naturally. 

For  example,  if  the  satellite  segment  is  implemented  on  the  satellite  data 
server,  the  network  will  not  experience  the  bulk  of  the  image  transfer  traffic.  In 
summary,  the  five  METOC  data  types  are  implemented  over  six  independent 
database  segments.  Since  the  original  implementation  [8],  the  observation  data  type 
has  been  further  divided  into  two  segments  to  enhance  performance.  The  volume 
of  the  satellite  observations  is  about  104  times  greater  than  that  of  the  conventional 
observations. 


III.  COMBINATIONS  OF  EXISTING  AND  NEW  TECHNOLOGY 
IN  THE  METOC  DATA  FLOW 

METOC  data  are  supplied  to  a  variety  of  Naval  systems,  including  but  not 
limited  to  the  Joint  Operational  Tactical  System  (JOTS)  and  Joint  Maritime 
Command  Information  System  (JMCIS)  [2,  3].  This  is  accomplished  through  a 
process  of  data  flow.  METOC  data  flow  is  an  important  feature  in  JMCIS.  The 
METOC  data  flow  is  described  below  as  an  example  of  how  existing  (E)  components 
will  interact  with  new  (N)  ones.  "(E,N)"  denotes  existing  components  with  planned 
upgrades.  The  following  is  a  plan  for  METOC  data  to  flow  into  and  out  of  specific 
components  of  the  Tactical  Environmental  Support  System /Next  Century  (TESS 
NC)  [8]  and  JMCIS. 

The  existing  Officer  in  Tactical  Command  Information  Subsystems  (OTCIXSs) 
(E)  provide  the  following  data  to  the  JOTS  1  ingest  (E)  platform:  Over-the-horizon- 
Targeting  Gold  (OTH-T-Gold),  GRID,  Bathythermogram  (BT),  Radiosond  (RDSND), 
MUNIT,  NUNIT,  and  OVLY2.  At  this  point,  the  data  stream  divides  and  two 
streams  result.  From  the  JOTS  1  ingest  (E),  one  data  stream  containing  the  OVLY1 
data  flows  into  the  JOTS  1  Global  database  (E)  and  the  remainder  of  the  data  stream, 
which  contains  OTH-T-Gold  messages,  flows  to  the  METOC  OTH-T-Gold  decoder- 
encoder  (E),  where  another  branch  in  the  stream  occurs.  One  branch,  consisting  of 
RDSND,  MUNIT,  and  NUNIT  data,  populates  the  JOTS  1  Global  database  (E).  The 
other  branch,  consisting  of  Gridded  Binary  (GRIB)  and  Binary  Universal  Form 
Representation  (BUFR)  data,  is  described  below. 

Data  Filter  and  Alert  Software 

This  particular  arrangement  of  data  flow,  of  which  GRIB  and  BUFR  are 
examples,  will  occur  in  several  places  throughout  the  data-flow  configuration. 
Therefore,  it  is  describe  here  for  future  reference.  GRIB  and  BUFR  data  are  fed  into  a 
filter  (N),  METOC  database  (N)  and  alert  software  (N)  arrangement  in  the  following 
manner.  Data  enter  the  filter-application  software  (N),  in  which  the  user  can  define 
thresholds  for  various  conditions  of  the  data.  When  the  data  have  passed  through 
the  filter,  they  are  stored  in  the  METOC  database  (N)  for  further  display,  analysis, 
and/or  processing.  When  an  event  is  detected  that  is  of  special  interest  to  a  user,  a 
threshold  is  exceeded  and  a  flag  is  raised  in  the  filter  software,  which  produces  an 
"alert"  message  (N)  on  the  user's  screen.  This  screen  could  reside  on  the  same 
hardware  platform  as  the  filter-application  software  (N),  or  it  could  be  on  a  different 
platform.  This  completes  the  description  of  the  OTCIXS  data  flow,  which  includes  a 
mixture  of  existing  and  new  capabilities.  (For  the  purpose  of  this  paper,  this  "filter- 
alert-database  arrangement"  is  called  the  Alert-Threshold  System  (ATS).) 

Naval  Modular  Automated  Communications  System 

The  next  data  flow  of  interest  pertains  to  the  Naval  Modular  Automated 
Communications  System  (NAVMACS),  which  provides  Optimal  Ship-Track  Route 


(OSTR)  information  and  warnings,  etc.  These  data  are  fed  into  the  JOTS  1  ingest  (E) 
machine,  and  thence  to  the  JMCIS  Central  Database  System  (CDBS)  (E),  and  thence 
to  message  applications  (E). 

METOC  Image  Format  (MIF)  data,  originally  from  a  AN/SMQ-11  via  the 
Secret  Internet  Protocol  Routing  Network  (SIPRNET)  or  the  Naval  Internet  Protocol 
Routing  Network  (NIPRNET)  (E),  enter  a  filter  application  (N)  described  above  in 
the  section,  "Data  Filter  and  Alert  Software."  (See  also  data-flow  description 
pertaining  to  the  MINI  Rawinsonde  System  (MRS).)  Here,  metadata  pertaining  to 
MIF  are  screened  and  alerts  are  issued  to  the  user’s  screen  on  the  basis  of  some 
previously  defined  metadata  features.  MIF  data  flow  into  an  application  (N)  that 
will  store  MIF,  and  thence  to  an  NT  File  Server  (E).  From  this  file  server,  MIF  data 
flow  to  a  viewing  and  conversion  application  (N)  that  will  allow  users  to  see  MIF 
images  on  the  NT  File  Server  (N).  This  application  will  allow  the  user  to  select 
specific  MIF  files  and  store  them  in  NITF  format  on  the  Image  Translation  Server 
(ITS)  (E).  From  ITS  (E),  image  metadata  are  transferred  to  the  JMCIS  CDBS  (E). 
Everything  in  this  figure  depicts  new  capabilities,  except  the  NT  file  server,  the  ITS, 
and  the  JMCIS  CDBS. 

Shipboard  Meteorological  and  Oceanographic  Observing  System  (SMOOS) 
data  have  two  separate  but  related  data-flow  paths.  SMOOS  sensor  data  flow  into  a 
SMOOS  ingest  (E,N)  module.  From  there,  BUFR  data  are  transferred  into  another 
ATS  (N)  described  above. 

Another  data  path  begins  with  global  and/or  local  observations  (Obs), 
including  upper-air  Obs,  Terminal  Aerodrome  Forecasts  (TAFs),  BTs,  and  warnings. 
These  data  sets  are  transmitted  to  a  module  called  "Other  Serial  Ingest,"  (E,N)  from 
whence  World  Meteorological  Organization  (WMO)  and  BUFR  data  proceed  to 
another  ATS  (N).  MRS  data  flow  into  the  METOC/MRS/OTH-T-Gold  decoder- 
encoder  (N),  and  thence  to  the  JOTS  1  JMCIS  Global  database  (E).  The  MRS  data  also 
flow  through  the  filter-alert-database  arrangement  (N),  now  called  the  ATS. 

Data  Sets  From  SIPRNET  and  NIPRNET 

This  section  explains  the  origin  of  various  data  sets  from  SIPRNET, 
including,  but  not  limited  to  MIF  data.  SIPRNET  or  NIPRNET  (E)  provides  a  group 
of  data  sets  called  "METOC  BUNDLE"  to  a  "METOC  Pull /Retrieve"  (N)  module. 
METOC  BUNDLE  can  contain  multiple  data  sets  with  several  items  of  interest, 
including  MIF,  BUFR,  GRIB,  WMO,  and  OTH-T-Gold.  The  "METOC  Pull/Retrieve" 
(N)  module  has  a  graphical  user  interface  (GUI)  for  the  user  to  specify  the  data  sets  to 
get  from  Fleet  Numerical  Meteorological  and  Oceanographic  Center  (FNMOC)  and 
regional  center,  or  any  METOC  database.  Data  in  a  compressed  format  proceed  from 
the  "METOC  Pull /Retrieve"  (N)  module  to  an  "UNPACKER"  (N),  module  that 
"unpacks"  the  data.  MIF  data  sets  are  among  the  unpacked  data  that  serve  as  input 
into  the  following  data  flow:  MIF  data  are  filtered  through  an  ATS  and  sent  to  an 
NT  platform.  There,  these  data  are  converted  manually  from  MIF  to  National 


Image  Transmission  Format  (NTIF)  and  are  sent  to  an  ITS.  Similarly,  the  other  data 
sets,  BUFR,  GRIB,  and  WMO,  also  proceed  through  the  data  pathways  consisting  of 
other  ATSs  (N).  The  exception  is  OTH-T-Gold,  because  these  data  undergo  an  extra 
step  between  the  UNPACKER  (N)  and  the  ATS  (N).  From  the  UNPACKER  (N), 
OTH-T-Gold  data  flow  through  a  METOC  OTH-T-Gold  Decoder  (N),  the  output  of 
which  consists  of  the  GRIB  and  BUFR  data.  These  GRIB  and  BUFR  data  flow 
through  the  ATS  (N).  Conceptually,  one  can  have  a  separate  ATS  for  each  data  type 
to  which  this  pertains.  However,  the  actual  implementation  may  result  in  a  single 
set  of  filter-alert-database  software  that  is  capable  of  detecting  and  processing 
multiple  data  types  from  a  variety  of  different  sources. 

SIPRNET  or  NIPRNET  (E)  provides  a  variety  of  files  to  the  office-automation 
briefing  tools  (N).  The  user  can  transfer  files  via  three  main  data  pathways.  First, 
the  user  can  transfer  images  and  documents  between  SIPRNET  or  NIPRNET  (E) 
directly  to  the  office-automation  briefing  tools  (N).  Second,  the  user  can  transfer 
files  via  File-Transfer  Protocol  (FTP)  between  SIPRNET  or  NIPRNET  (E)  and  the  NT 
File  Server  (E).  Third,  the  user  can  store  and  access  office-automation  files  and  briefs 
from  the  NT  File  Server  (E)  into  the  office-automation  briefing  tools  (N). 

Data  Inputs  and  Outputs  and  Forecast  Tools 

This  section  describes  inputs  and  outputs  of  the  NT  File  Server  (E),  the 
METOC  Database  (N)  and  the  JOTS  1  Global  database  (E).  The  NT  File  Server  (E)  will 
supply  products  to  the  forecaster  tools  (N).  Forecaster  tools  (N)  also  can  store  new 
products  on  the  NT  File  Server  (E). 

The  forecaster  tools  (N)  also  will  interface  with  the  "METOC  database 
interface"  module  (N),  which  will  be  capable  of  interacting  with  many  other 
components.  For  example,  the  "METOC  database  interface"  module  (N)  will  be 
capable  of  interacting  with  the  METOC  database  (N),  the  JOTS  1  Global  database  (E), 
and  the  JMCIS  CDBS  database  (E).  One  of  the  new  technologies  being  combined 
with  existing  systems  is  more  extensive  use  of  access  to  METOC  data  via  the  World 
Wide  Web  [7],  More  specifically,  the  "METOC  database  interface"  module  (N)  will 
store  and  retrieve  data  from  the  METOC  database  (N)  via  three  modes  of  operation: 
APIs,  Ad  Hoc  Queries  (AHQ),  and  Web.  The  Web  mode  of  METOC  database  access  is 
as  follows:  Data  flow  to  and  from  a  METOC  Web  SERVER  module  (N),  which 
interfaces  with  a  database-to-web  converter  (N).  The  database-to-web  converter  (N) 
is  connected  to  the  METOC  database  (N)  to  provide  a  method  for  multiple  users, 
both  meteorologists  and  fleet  users,  (such  as  TAMPS,  etc.)  to  view,  and  in  some 
cases,  update  METOC  data. 

"METOC  database  interface"  module  (N)  will  interface  to  the  JMCIS  JOTS  1 
Global  CDBS,  TDBM,  etc.  database  (E)  via  "Non-METOC  Customers"  software  (N). 
Finally,  the  "METOC  database  interface"  module  (N)  will  be  capable  of  interacting 
with  the  JMCIS  JOTS  1  Global  CDBS,  TDBM,  etc.  database  (E)  via  the  COP  (E)  -  NITES 


II  applications  (N).  Data  will  flow  into  and  out  of  the  database  via  the  COP  (E)  - 
NITES  II  applications  (N). 


IV.  POTENTIAL  IMPACT  OF  NEW  TECHNOLOGY  ON  THE  METOC  DATA  SERVER 

The  computer  industry  has  produced  much-matured  software  and  hardware 
products  since  the  implementation  of  the  METOC  data  server  in  1997  [8].  All  of 
these  commercial  software  and  hardware  products  have  gone  through  years  of 
development  cycles.  A  few  of  these  technologies  have  matured  enough  that 
METOC  community  must  pay  attention  to  them  and  perform  analyses  to  examine  if 
these  technology  can  be  harvested  to  improve  the  METOC  database  system. 


Advances  in  Metadata 

METOC  database  is  a  metadata  system.  The  metadata  schema  is  implemented 
on  a  relational  database  management  system  (RDBMS)  while  the  bulk  of  the  data 
themselves  are  left  as  either  flat  files  or  a  binary  large  object  in  the  RDBMS.  Among 
all  metadata  advances  (e.g.  data  warehouse),  a  key  development  for  the  spatial  data 
in  the  federal  government  is  worthy  of  attention.  Using  the  data  warehousing 
concept,  the  metadata  sever  can  be  used  to  dispatch  the  request  to  a  physical  data 
node  and  also  can  be  used  to  house  the  middleware  for  data-access  methods  and 
translations.  The  Federal  Geographic  Data  Committee  (FGDC)  has  defined  the 
Content  Standards  for  Digital  Geospatial  Metadata  (CSDGM),  and/or  descriptions  of 
the  available  non-geospatial  information  (e.g.,  documents,  algorithms  and  tools) 
using  the  Government  Information  Locator  Service  (GILS)  metadata  standard 
location.  These  metadata  records  are  indexed  using  Wide  Area  Information  Servers 
(WAIS)  software,  and  are  made  available  to  Internet  WAIS  search  clients 
communicating  with  the  WAIS  standard  protocol  (an  early  version  of  ANSI  Z39.50). 


World-Wide  Web 

One  of  the  most  recent  and  user-friendly  developments  in  the  area  of  data 
access  for  the  database  community  in  general  has  been  the  use  of  the  World  Wide 
Web  (WWW).  For  the  METOC  users  in  particular,  access  is  via  the  Joint  METOC 
Viewer  (JMV).  [7]  Using  JMV,  METOC  numerical  data  and  products  are  available 
for  downloading  by  geographic  region.  These  data  include  surface  pressures  and 
temperatures.  Still  a  wider  variety  of  data  are  available  for  display  as  images  in 
windows  on  the  screen.  For  example,  the  user  can  display  profiles  and  cross  sections 
of  three-dimensional  atmospheric  and  oceanographic  data  [7].  The  WWW  has  the 
advantage  of  being  independent  of  the  hardware  platform  because  network 
browsers,  using  a  common  Hypertext  Mark-up  Language  (HTML)  protocol  for  net 
access,  are  available  for  many  platforms  [7]. 


Object-Oriented  Methods 

Since  1985  [5,  6, 11],  the  object-oriented  (OO)  database  design  has  been 
researched  and  developed  for  handling  data  that  can  not  be  managed  easily  using 
RDBMS.  However,  an  object-oriented  database  is  recommended  to  be  implemented 
with  applications  of  the  same  design.  Otherwise,  the  advantage  of  the  OO 
technology  will  be  nullified  in  the  heavy  translation  layer.  To  integrate  an  OO 
database  with  legacy  applications,  the  full  benefit  of  the  technology  may  not  be 
realized  because  of  the  need  of  a  translation  layer.  The  METOC  RDBMS  data  server 
has  experimented  in  using  Common  Object  Request  Broker  Architecture  (CORBA) 
to  wrap  a  data  object  extracted  from  a  METOC  database  and  allow  designated 
applications  to  access  the  data  object  in  a  "plug-and-play"  mode.  The  wrapper  is 
embedded  and  implemented  in  the  APIs.  The  results  demonstrated  that  though  the 
CORBA-wrapper  technology  worked,  the  a  re-evaluation  of  the  system  is  still 
needed.  However,  the  recent  development  of  Java,  an  OO  and  platform- 
independent  programming  language  developed  by  Sun  Microsystem,  should  not  be 
ignored.  Because  of  its  platform  independence,  Java  can  be  used  to  control  the 
protocol  in  downloading  data  objects  from  the  data  servers  in  a  variety  of  different 
environments.  A  distributed  database  server  can  be  constructed  to  take  advantage  of 
Java  technology  by  using  the  WWW  technology. 

Multimedia  Technology 

Though  METOC  data  types  have  included  images  since  late  1950s,  they  have 
existed  largely  in  the  single  image  or  observation  format.  The  emphasis  of  the 
METOC  satellite  technology  has  been  on  the  quality  and  resolution  of  the  data. 

Since  the  recent  explosion  of  the  "compute  power"  from  a  PC /NT  workstation, 

PC /NT  has  been  recognized  as  a  bona  fide  data-processing  and  display  workstation 
in  the  Department  of  Defense  (DoD)  systems.  The  directive  of  the  Information 
Technology  for  the  Twenty-First  Century  (IT21)  is  a  reflection  and  an 
acknowledgment  of  this  trend.  The  maturity  of  the  multimedia  hardware  and 
software  already  has  transformed  the  training  and  documentation  technology. 
METOC  data-monitoring  and  alerting  functionality  soon  will  adapt  the  technology 
as  well.  In  the  near  future,  the  demand  of  the  storage  and  retrieval  of  acoustic 
recordings  along  with  other  nature  environmental  data  soon  will  push  METOC 
data-server  managers  and  engineers  to  consider  the  multimedia  technology. 

Network  Communication 

The  advances  of  the  communication  technology  could  overhaul  the  METOC 
data  flow  and  the  concept  of  operations.  The  change  is  likely  to  come  from  the 
virtual  network  capability  first.  All  computers  in  DoD  systems  soon  will  be  linked 
or  addressable  through  some  network.  Further  in  the  future,  the  communication 
bandwidth  will  overhaul  the  data-flow  concept  of  operations.  The  bandwidth  could 
change  the  data  flow  from  the  cascading  "hub  and  spoke"  concept  to  a  point-to-point 
data  flow  concept.  It  can  be  envisioned  easily  that  all  applications  (or  clients)  could 


come  directly  to  the  data-producing  centers  to  obtain  the  desired  data.  When  the 
data-  producing  centers  implement  fault-tolerant  capabilities,  a  true  federated 
database  can  be  formulated  through  the  wide  bandwidth  network.  (See,  for  example 
[2]).  However,  this  change  will  not  come  quickly  since  it  is  suspected  that  as  the 
bandwidth  increases,  the  data  volume  grows  accordingly.  The  available  portion  of 
the  shared  bandwidth  is  likely  to  remain  the  same. 

V.  DISCUSSION 

In  the  next  three  years,  the  advances  in  scientific  tools  as  well  as  new 
computer  technologies  inevitably  will  force  changes  in  database  design. 

Furthermore,  the  same  advances  also  will  change  the  user  requirements.  And,  in 
turn  the  users  will  force  the  change  in  database  server  design.  The  METOC  database 
server  is  poised  to  take  advantages  of  these  changes  and  technologies. 

The  METOC  database-server  design  can  take  advantage  of  the  extension  of  the 
communication  network  capability.  The  exist  RDBMS  capability  already  can  be 
configured  to  formulate  a  distributed  database-server  capability.  With  the 
designated  hierarchy  of  the  data  flow,  applications  can  extracted  data  form  a 
transparent  distributed  database  server. 

The  metadata  advances  could  possibly  give  the  community  the  opportunity 
to  link  up  the  entire  legacy  database  systems.  This  concept  can  be  extended  to 
imagine  that  all  federal  government  (at  least  in  the  METOC  community)  database 
servers  will  have  the  capability  to  exchange  data  sets. 

The  WWW  and  Java  constitute  a  significant  advance  in  heterogeneous 
computer  environments  to  provide  a  set  of  platform-independent  protocols  for  data 
object  transfer  and  processing.  The  METOC  database-server  engineers  are 
examining  such  capability.  As  the  effective  communication  bandwidth  increases  in 
the  coming  years,  the  "data  pull"  concept  from  individual  applications  can  be  fully 
implemented. 

Though  the  METOC  database  server  schema  can  be  extended  to  accommodate 
the  multimedia  data  type,  the  task  is  not  straightforward.  The  METOC  community 
has  not  explored  fully  the  use  of  multimedia.  The  design  of  a  data  type  in  next  two 
years  to  describe  fully  the  attributes  and  services  of  multimedia  will  not  be  easy. 

VI.  CONCLUSION 

One  of  the  most  important  conclusions  is  that  not  all  technology  can  be 
mapped  efficiently  into  METOC  (or  any)  database.  One  needs  to  understand  the 
requirements  of  the  users  and  select  the  technology  combinations  that  meet  their 
needs  as  a  priority.  Typically,  DoD  systems  cannot  afford  to  upgrade  constantly  to 
new  technology  as  soon  as  it  becomes  available.  Moreover,  if  and  when  to  use  a 
technology  and  when  not  to  use  it  is  not  always  obvious.  Therefore,  a  system 
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designer  must  develop  a  list  of  criteria  to  consider  when  deciding  if  and  where  it  is 
appropriate  to  use  a  technology.  These  criteria  will  be  based  on  the  trade  offs,  but 
always  will  include  a  view  toward  meeting  users'  requirements.  When  upgrading 
modern  systems,  engineers  usually  cannot  obtain  the  full  set  of  requirements  at  the 
onset  of  the  project.  The  rapid  technology  advances  combined  with  the  new  and 
modified  user  requirements  often  will  invalidate  the  trade-off  analysis  at  the 
beginning  of  the  project.  Therefore,  modern  systems  must  be  constructed  to 
anticipate  and  accommodate  these  advances  and  changes.  METOC  database  uses  the 
layered  approach,  unified  design,  data-centric  perspective,  and  modular  construction 
principles  to  accommodate  the  technology  advances  and  requirement  changes. 
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APPENDIX  A  -  GLOSSARY 


ANSI 

ATS 

BT 

BUFR 

C3I 

CDBS 

COP 

CORBA 

CSDGM 

DBMS 

DH/COE 

FGDC 

FNMOC 

FTP 

GILS 

GRIB 


American  National  Standards  Institute 
Alert  Threshold  System 
Bathythermograph,  Bathythermogram,  or 
Bathythermography,  depending  on  usage 
Binary  Universal  Form  for  the  Representation  of 
Meteorological  data 

Command,  Control,  Communications  and  Intelligence 
Central  Database  System  or  Central  Database  Server 
Common  Operating  Picture 
Common  Object  Request  Broker  Architecture 
Content  Standards  for  Digital  Geospatial  Metadata 
Database  Management  System 

Defense  Information  Infrastructure  Common  Operating 
Environment 

Federal  Geographic  Data  Committee 

Fleet  Numerical  Meteorological  and  Oceanographic  Center 
File-Transfer  Protocol 
Government  Information  Locator  Service 
Gridded  Binary 


GRID 

GUI 

HTML 

IME 

ITS 

JMV 

JOTS  1 

JMV 

METOC 

MIF 

MRS 

MUNIT 


NAVMACS 

NEONS 

NIPRNET 

NITES 

NITF 

NODDS 

NUNIT 


OODBMS 

OSTR 

OTCIXS 

OTH-T-Gold 

OVLY2 

RDBMS 

RDSND 

SIPRNET 

SMOOS 

AN/SMQ-11 

SQL-92 

TAF 

TDBM 

TEDS 

TESS/NC 

WAIS 

WMO 

WWW 


Not  an  acronym  but  a  data  format 
Graphical  User  Interface 
Hypertext  Markup  Language 
Information  Management  Engineering 
Image  Translation  Server 

Joint  METOC  Viewer,  a  multiplatform  client-server 

application  suite  that  builds  upon  NODDS  and  WWW 

Joint  Operational  Tactical  System  1 

Joint  METOC  Viewer 

Meteorological  and  Oceanographic 

METOC  Image  Format 

MINI  Rawinsonde  System 

Modified  Index  of  Refraction  (M-Unit).  An  atmospheric  Index  of 
Refraction  mathematically  modified  so  that  it  substantially 
corrects  for  the  curvature  of  the  earth.  (See  NUNIT.) 

Naval  Modular  Automated  Communications  System 

Naval  Environmental  Operational  Nowcasting  System 

Navy  Internet  Protocol  Routing  Network 

Navy  Integrated  Tactical  Environmental  Subsystem 

National  Image  Transmission  Format 

Navy  Oceanographic  Data  Distribution  System 

Index  of  Refraction  of  the  atmosphere  (N-Unit).  A  measure  of 

the  amount  of  atmospheric  refraction.  It  is  the  ratio  of  the 

wavelength  of  an  electromagnetic  wave  in  a  vacuum  to  that  in 

the  atmosphere.  NUNIT  is  not  corrected  for  the  curvature  of  the 

earth.  (See  MUNIT.) 

Object-Oriented  Database  Management  System 
Optimal  Ship-Track  Route 

Officer  in  Tactical  Command  Information  Exchange  Subsystem 
Over-the-Horizon-Targeting  Gold  (a  message  format) 

Overlay  2  (Part  of  OTH-T  specifications) 

Relational  Database  Management  System 

Radiosond  message  format  for  OTH-T  messages 

Secret  Internet  Protocol  Routing  Network 

Shipboard  Meteorological  and  Oceanographic  Observing 

System 

Army  /Navy  satellite  receiver  for  the  military  satellite 
counterpart  of  the  GOES 

Structured-Query  Language  specified  by  ANSI  X3. 135-1992 

Terminal  Aerodrome  Forecast 

Track  Database  Manager 

Tactical  Environmental  Data  System 

Tactical  Environmental  Support  System /Next  Century 

Wide  Area  Information  Servers 

World  Meteorological  Organization 

World  Wide  Web 
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